Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

CuriosiTy Shapes the Mind

SBroder99 — Fri, 02 Dec 2022 08:23:00 GMT

There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.

T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace. I’ve recently started unpacking my own unique skills and attributes to see what T shaped skills I have developed in my personal life and career. I keep coming back to curiosity. It’s the one trait that delivers on so many attributes on the horizontal line. In this post, I am going to explore what ‘being curious’ means to me.

“Curious about people, ideas and challenges”

One rather simple sentence but encompasses so much.

Curious about yourself and others will develop self awareness, empathy, communications and personal development.

Curious about ideas will develop learning and understanding.

Curious about challenges will develop innovation, problem solving and resilience.

Starting with the things you are interested it in from hobbies to studies is a great way to expand or improve those vertical skills. You may not necessary need the skills today or tomorrow but you will be ready for when the opportunity comes your way.

#StayCurious

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

Understanding Machine Learning Models

Arash — Thu, 01 Aug 2019 18:42:00 GMT

Machine Learning (ML) models are intended to positively impact business efficiency. By understanding how these models are created, how they function, and how they are put into production, one can fully utilize their potential to make a difference in every day scenarios.

What is a Machine Learning Model?

By creating cases within a narrow domain, such as a car insurance company assessing the risk of a particular vehicle being stolen based on known statistics, a machine learning model will use algorithms to determine probability and associate this probability with a particular outcome. While such algorithms are not necessarily limited to particular scenarios, they can be programmed to a higher degree of accuracy for specific types of questions. Below are some use cases that exemplify ideal machine learning models.

What are referred to as regression questions. These would include ‘How much’ and ‘how many’.
Classification questions that include ‘Type of object’ scenarios.
Questions that enable the model to group or cluster in order to resolve a particular scenario.
What are known as ‘abnormality detection questions’ that pinpoint unusual situations.

Engineers and data scientists use tools, frameworks and codes to build models, often from massive amounts of data.

In fact a really effective machine learning model uses enormous amounts of data that ideally has been cleaned and labelled. The process is iterative and involves both trial and error using tests and measures. Multiple steps and processes are used in creating a machine learning model. The finished model enables the computer to use different cases within a particular scenario in order to reach a viable resolution.

Using the answers to specific questions within an array of proven cases, the machine learning model provides users with guidance based on the probability that a particular solution is correct. For example, are particular symptoms indicative of a known medical problem, can this product be fixed, or is this a fraudulent financial transaction?

The Practical Utility of Machine Learning Models

Machine Learning models are intended to achieve the following outcomes:

Use on-the-fly or batch cases to integrate the model systematically
Combine several models to answer complex questions that require multi-step answers
Utilize models to assist with organizational decision making or with external contacts
Integrate workflows and processes that involve several participants
Use certain information system related algorithms with minimal code revision
Provide analytics as a service by sharing the model between multiple use cases.

Monitoring and measuring the machine learning models in a live environment is crucial. In so doing, a cycle of constant improvement is employed. While individual models are not as useful as those that are part of a more sophisticated deployment involving multiple scenarios. In such cases, the solutions suggested should be run against to a decision model that is based on a domain expert’s knowledge and consequently be implemented by using predefined business rules.

As mentioned above, a machine learning model may be designed by an insurance company using statistics that detail the likelihood of a particular car being stolen. The model will categorize a car as low, medium or high risk.

Consequently, calculating an insurance quote for a specific vehicle involves the system calling to a machine learning model which will then identify the likelihood of it being stolen. The result is then sent to the quote generation process to calculate the cost for an insurance policy.

Conclusion

Experience has shown that machine learning models need to be integrated as part of a business decision and process in order to be used effectively. These models must be able to execute requests on-the-fly and their performance within a particular knowledge domain must be monitored, measured, and improved over time.

For more information, please visit http://www.flexrule.com.

Requirements In Context Part 2: The Functional View From 10,000 Feet

Dan Tasker — Mon, 29 Apr 2019 00:49:00 GMT

In Part 1 of this series it was stated that the overall objective of these articles is to improve the quality of requirements produced by business analysts. Following the adage that “Context is Everything” it established that a number of different contexts will be explored. And in keeping with this principle it set business information systems as the context of the requirements to be addressed.

Classic Business Functions

My very first position as a business analyst 30 years ago was with a company that had just completed an enterprise-wide planning effort.⁽¹⁾ They had gone so far as to remodel one of their conference rooms for the specific purpose of displaying the results on multi-layered whiteboards. The most prominent board displayed a functional model of the business. It was said to be a view of the company from 10,000 feet up. The functions were organised into three categories: Management, Support and Line of Business.The following diagram is a slightly simplified version of that model:

In my first article I presented the classic “Swings” cartoon. It is a classic because it has remained relevant all these years. I consider the high-level functional model presented above to be a classic. It too has stood the test of time. Throughout my years as a business analyst, working in a wide variety of industry segments and government agencies in three countries, this model has proved to be both relevant and useful.

Not all organisations utilise every one of the functions shown. And some organisations have multiple lines of business. For example Walt Disney - Film production would be one, theme parks another. In this style of model, each would have its own ‘Line of Business’ functions to provide contexts for dealing with very different products. Regardless of the numbers of lines of business, the Management and Support functions are applicable across the organisation.

Enterprise Resource Planning

Thirty years ago using a model like this to plan an organisation’s business information systems was leading edge. Database management systems had been around just a few years. Their use typically involved one-for-one replacement of application-specific files. A batch processing inventory management system would be upgraded to an online inventory management system supported by an inventory database. A batch processing sales management system would be upgraded to an online sales management system supported by a sales database. And on and on.

High-level functional models like this were used to demonstrate to the organization that a shared set of data could and should be used to support multiple functions across the business. The idea was to stop developing application-specific information systems and start developing an enterprise-wide one. Fast forward to today and this vision has become business as usual for many organisations.

It is common today for an organisation to have a relational database that holds data utilised by multiple business functions. Some of these systems have been developed in-house. Others utilise one of the commercially available Enterprise Resource Planning (ERP) systems. Probably the original and best known of these is SAP. The following is a list of integrated SAP modules that an organisation to pick and choose from:

Human Resource Management
Production Planning
Material Management
Financial Supply Chain Management
Sales and Distribution
Project System
Financial Accounting and Controlling
Plant Maintenance
Quality Management

Quite a striking correlation between these modules and the high-level functions from that 30 year old model.

High-level Requirements From High-level Functions?

This series of articles is about requirements in context. The Functional context is where we are starting. The functions from the 10,000 foot level are the most general functional context I can imagine. Could these be used to draft requirements? I can think of one scenario where they could - an organization interested in acquiring an ERP system. Here is an example of one such high-level requirement:

The system shall support Accounting processes integrated between themselves and with processes of other functions.

Each ERP function the organisation is interested in should have its own requirement naming a high-level function it wants within its integrated system. Each would be assigned its own priority. Some would likely be must haves while others might only be nice to haves. (Who am I kidding? – we all know that to business users every requirement is a ‘must have.’)

Processes within Functions

The view from 10,000 feet is an interesting functional context, but outside of acquiring an ERP system we need business functions closer to earth. Fortunately the majority of functional modelling techniques include the concept of functional decomposition. That technique used to produce the model above offered a simple three-level decomposition scheme. The things at the top level were called Functions. A level below functions were things called Processes. The third and lowest level things were called Activities.

Functions were considered to be ‘ongoing’ activities. A person working in Accounting or HR does their job year round, year in and year out. Processes in the context of this model were defined to be things that have a start and an end point. A given Function typically would decompose into 10-ish Processes. Again using SAP as an example, we see its HR module breaks down into 12 processes:

Organizational Management
Personnel Administration
Recruitment
Payroll
Travel Management
Personnel Management
Time Management
Compensation Management
Training and Event management
Wages
Personnel Development
Workforce Administration

It’s easy to envision most, if not all of the above processes having start and end points. For example, while it could be argued that Recruitment goes on continuously, in reality filling a specific position starts with some form of notification of the opening and ends ideally with a successful candidate coming on board. Here is an example of a high-level requirement utilising a Process context:

The system shall support the recruitment process including keeping records of published notifications, candidates, interviews and proof of fairness during the selection process.

Activities within Processes

The term Activity can be defined as the individual steps in a process. Visualise a workflow diagram. The boxes in the diagram that don’t themselves require further decomposition would be considered activities. The basic idea is that an Activity is that it should be simple enough that an individual is able to complete it in a single ‘sitting.’ No need to hand the work off to anyone else mid-activity or to have to wait for some other activity to complete. An example of an activity within the Recruitment process would be one called “Make Offer to Candidate.” An example of a high-level requirement ustilising an Activity as a context would be:

The system shall support keeping a record of offers made to selected candidates.

I have used a variety of functional modelling techniques from dataflow diagrams to business process modelling notation (BPMN). Regardless of the terminology used in any particular method, I have found the definitions of the three functional levels presented above to be excellent guideposts for both functional modelling and drafting requirements.

Next Time – Project Scope as a Context for High-Level Requirements

Gathering of requirements is typically managed within a project, and part of managing a project is establishing its scope. Requirements are expected to address the things within this scope. Next time we will look at scope and how high-level requirements can be derived directly from it, and actually as part of the scoping effort.

(1) The enterprise-wide planning methodology utilized by the company described was called Strategic System Planning (SSP) developed by Robert Holland.

Pablo Picasso and Scope Visualization

Paul Crosby — Wed, 07 Sep 2016 14:28:00 GMT

Scope – the last frontier. We are on a mission where no business analyst has gone before. To explore strange new diagrams and to have the project scope clearly understood. Extra credit to those who remember which TV show that was from! Scope and context are the number one reason business expectations about a project are not met, and projects fail.

Let’s face the reality. Projects today are more complicated. In this integrated and connected world of systems long gone are the days of the quick and easy change. Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs. Symbols and shapes connected by lines that fill the wall of an entire room. Even trying to explain the diagram to someone can take days.

Projects now require more involvement by more people. Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all. Stakeholders are flung across the globe speaking many different languages. Top it off with organization’s taking on hundreds of projects at the same time. Keeping track of each project’s scope and impacts to the organization are difficult to comprehend. It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value. They lose sight of the project's vision and goals in our complex systems and processes. Everyone is one a different page. We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope.

So it’s no wonder that scope and context are the number one reasons projects fail. How can you get an entire project team moving in the right direction? Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project.

So how do we get everyone on the same page? By that, I mean the same page in the same book!

It’s time to visualize scope. Scope places the boundaries around where the entire project team will work. Bust out that context diagram. Getting a clear common understanding of scope and business expectations leads to better projects that deliver real value. Is that user story a complete representation of the project boundaries or scope? Maybe not. The EPIC or a bunch of user stories combined would be closer to the bulls-eye. A picture is worth a thousand words. Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.

Scope visualization isn’t just about a context diagram. That’s certainly a great tool, and I blogged about it previously. Don’t get me wrong – I love my context diagrams. Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams. In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers. Sticking 1,300 servers on a diagram was an exercise in futility. There just isn’t a big enough piece of paper to display them all. So I pictured things at a higher level. I presented each server farm as a farm – yup cows and red barn with Farmer Joe. The size of the farm was based on the number of servers on that farm. Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily. All of this was based on estimates from doing a high-level scan. Remember context is high level.

In each barn was an icon that represented a group of servers. There were three groups: leave it alone, upgrade it and consolidate then retire it. I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders. Servers were put into groups based on our best guess.

In the kickoff meeting, this was a great tool. Sponsor and stakeholders understood in the scope of the project. Yes, they wanted to know more. Everyone wants to know the details, but we were just starting out. Everyone walked out of the room with a pretty good understanding of the scope and estimated size. Many were surprised at the volume of servers in each farm. Overall the infographic did an excellent job of setting the stage for the project visually. All on one PowerPoint slide.

The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people. That’s no easy task. Taking the complex and making it simple is powerful. It creates a better shared understanding of the project.

The business wanted a global CRM solution, but all they got were pigeons and index cards. Yeah, that is why context is important.

Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project. It’s important that all throughout the project to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope.

I take the concept of the context diagram a little farther than how most folks typically use a context diagram. You know me always pushing the envelope. Context diagrams usually explain the end state or the outcome of the project. They show the scope of a project outcome.

Building on a good thing, I like to build a context diagram of the current environment at a high level. Even at a high level, I’m often surprised at how differently stakeholders, sponsors, and team members view the current state. It’s a great tool to get everyone on the same page for the starting point. Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination. Knowing where you are starting from is a powerful thing when to explain where you want to end up in the future state.

Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state. Not many projects look at the desire of the stakeholders and sponsors. The desire is stated in the project request form or project charter. The sponsor and stakeholders put together a vision of the expected outcomes in these documents. A context diagram of the project charter or request which elaborates the vision is a powerful thing. It ensures what is being asked for is understood.

Don’t re-invent the wheel. Many times I take the current state diagram and just highlight the areas that are changing. Use color to highlight the add, modify or removes based on the context diagram for the current state. Color visually explains where the changes are visualized to occur.

Now you may think I completely lost my mind at this point. Fear not I’m taking a step even further. I take the context diagram that shows the desired state (based on the project charter or project request) and determines what is feasible. Everybody wants it all but the teleporter to zap you across the globe for a break in Paris hasn’t been built yet. Reality always steps in and dictates what is feasible. Taking the context diagram I will highlight the areas that are NOT feasible. It’s a great way to level set the expectations of the sponsor, stakeholder and project team members.

So when in the project life cycle does all this context stuff happen? Ideally, it should happen before the project starts at a very high level. Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome? You can bet it would save a lot of time running around trying to get everyone on the same page. Typically, the context is set at the start of the project.

As you move through the project, more and more understanding is acquired. Details need hammering out and there is ALWAYS change to the project. Has anyone ever worked on a project with absolutely zero change? If you have, you are leading a very charmed existence. I’m jealous. Context diagrams can help evaluate how a change would impact the project. So forget about laminating them and hanging them on the wall. They are living breathing documents that will change throughout the life cycle of the project.

The pitfall is that architects and others might expect diagrams that show the smallest of components. Don’t fall into that pit. Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out. Detail is important for design but scope context requires things to start at a very high level and be decomposed into more information. Context is simple with enough detail to make it clear.

Break out your inner Pablo Picasso and get creative. Find a way to display context or scope in a visually appealing manner. Color can help bring greater clarity. Highlight areas in different colors to bring focus to them. If a system is risky or substantially impacted by the project scope, highlighting is a technique to denote that risk. Black & White isn’t your friend. Studies have shown that color diagrams – even with a small amount of color – are more memorable.

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today. Bob the BA offers the Badass BA workshop and Enterprise Analysis workshop which covers this technique in more detail.

Quick Intro to Decision Model and Notation - DMN

Arash — Wed, 10 Aug 2016 23:03:00 GMT

Decision Model and Notation in short DMN is a novel way to model business decisions. DMN allows capturing and modeling business decisions in a way that is easy to understand with business people and subject matter experts. It is a combination of:

Decision requirement diagram – DRD
Decision table
Boxed expressions
Friendly Enough Expression Language – FEEL

Decision Requirement Diagram (DRD)

This is a graphical model that allows modeling dependencies between input data, decision, business knowledge and knowledge source.

In DRD, the arrows show the dependencies between different nodes in the model. To put it in a simple way, you can read it as if the output result of some nodes will be passed as the input of the other nodes.

In the table bellow, all the elements on a DRD model are illustrated:

ELEMENT	NOTATION	DESCRIPTION
Decision		The act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models.
BusinessKnowledge Model		A function encapsulating business knowledge, in the form of business rules, decision table or analytic model. Some of the tool may not support this element. In such case the decision logic is directly linked to the Decision rather than the business knowledge model.
KnowledgeSource		The authority for a business knowledge model or decision.
Input Data		Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model.
Information Requirement		Information – input data or decision output – required for a decision.
Knowledge Requirement		The invocation of a business knowledge model.
Authority Requirement		Showing the knowledge source of an element or the dependency of a knowledge source on input data.

Decision Table

In decision model and notation, the Decision Table is a tabular form that models rules based on conditions and actions which they are also called inputs and outputs. Decision Table is the default type of modeling business rules in DMN. But if your tools support other ways to model business rules then you can freely use them along side with decision table.

Boxed Expressions

In Decision model and notation (DMN) are a simple two column table and effective way to model business formulas, calculations, values and expressions. And then you can share them across multiple decisions and logic.

Boxed expressions simply allows modeling: constant, values, invocation, formulas… Boxed expressions allows putting together building blocks of logic (i.e. decision table, natural language, flow…) and reuse them over and over again.

Friendly Enough Expression Language

In decision model and notation, FEEL is an expression language for business people. FEEL define a syntax for expressing conditions, actions and formula. Consider FEEL like excel formulas that they allow you formulate your thinking about a domain in a context. FEEL is designed to allow ease of use by business people and subject matter experts.

Advantages

There are benefits of using decision model and notation over the traditional business rules approach. In the business rules approach, very soon you start thinking about the business rules which they are more about the logic implementation. But decision approach provides a more high-level abstracted layer that allows you to see the big picture first rather than diving deep into implementation and losing the context and overview of the solution.

This change of approach:

Allows scaling business rules in more manageable, reusable visual approach across applications and processes.
Allows better communication between business, domain experts and IT by enabling a productive involvement of business people and subject matter experts.
Allows clearly define decision boundaries and expose the decision as a service with a click!

If your tool supports simulation and execution, error checking at design time and runtime with debugging capability then you will not miss anything from business rules approach, but also will have a better way to reuse and scale your business rules in a systematic way.

Submitted by: FlexRule

Top 10 mistakes in Use Case Modelling

Trividh Patel, CBAP — Mon, 11 Jan 2016 03:10:00 GMT

Use case modelling is the most powerful requirements modelling technique to model solution requirements if applied correctly. I have come across many BA teams (including my own) that made lot of common mistakes in use case modelling. By avoiding the top 10 mistakes identified in this paper, BA teams can not only save lot of efforts in use case modelling but also significantly enhance the value delivered and improve the satisfaction of stakeholders.

1. Naming the actors using the job titles

Job titles and actor names are two different things and often cause confusion. This is because two different users, with different job titles and organizational responsibilities, may have to use the system as a same actor; for example, a supervisor can have access to and use the functionality used by his/her subordinate. Actor is a role that is with respect to the system as opposed to a job title which a role with respect to the organization. Job titles may typically determine user types. Remember, job titles of people may change but the roles they play would remain relatively stable.

2. Creating only the use case diagrams

Use case diagrams only provides summary of the relationship between the actors and the use cases. Can we tell what a system does basis only the use case diagram? No; a system cannot be built just based on the use case diagrams. We need detailed use case descriptions to design and build the system.

3. Not capturing enough details

Too much detail can obscure the flow of the use case and too less can make it really meaningless. “How detailed a use case should be?” In as much detail as possible and in as much detail that is required to make them unambiguous to describe what the system must do. Focus on what is important and continue to add details till all the stakeholders are satisfied.

4. Describing everything a system does in a use case

It is important to identify all the use cases and describe them so that everyone understands who uses the system and what goals they achieve by using it. This is particularly important when the user-system interaction is complex and detailing the system behaviour is essential to develop and test the system. However, if we blindly do this for all the use cases than we are just increasing the documentation and subsequent time required for reviews and sign-off, without delivering any additional value to the project and its stakeholders. So, for cases where the user-system interaction is simple, use cases are not required to be fully described. In such cases, a simple use case description supplemented with declarative requirements and other models may be sufficient to understand what needs to be done.

5. Performing functional decomposition

BA teams typically tend to group functional requirements, or break them in form of functions or menu-items and identify them as use cases. What they don’t understand is, high-level use cases cannot be decomposed into lower-level use cases and also use cases cannot call, communicate, get linked or sequenced with other use cases. This approach is most common of all mistakes made while identifying and describing use cases. Let us try to understand this with an example.

What use cases will you identify for a system say, a car? The adjoining diagram shows the use cases identified using this approach. Here, all the necessary functions (menu-items!) are available to a ‘Car Driver’ (actor) to drive a ‘Car’. With this approach, are we answering what the ‘Car Driver’ will do to drive (actual goal) the ‘Car’? None of the use case actually describes the way ‘Car Driver’ will interact with (or use) the ‘Car’ to drive it without linking or sequencing them. The system appears as a large set of disconnected functions. To identify the right use cases, always keep in mind the goal that the actor wants to achieve by using the system. Each use case must be complete to provide value to at least one of its actors.

6. Writing perfect use cases

There is no such thing as perfect use cases. Many BA teams waste their efforts in trying to create perfect use cases. The focus should be on making use cases as good as required for facilitating communication amongst stakeholders to achieve shared understanding of requirements and moving to system design, development and testing.

7. Detailing use cases with the CRUD behaviour

Although it is not technically wrong but detailing uses cases with CRUD (create, retrieve, update, delete) behaviour, for example maintaining information for administrative systems, is a waste as it is mere repetition of declarative form of requirements specifications. Use cases with the CRUD behaviour don’t add much value to ensure that the system is doing right, particularly when information can be added in any sequence without any dependency. Except for data validation rules and specific fields to be entered, the use cases with the CRUD behaviour become repetitive. These efforts can be used for detailing use cases with real flow of events.

8. Using the use case model to design the system

Many times, BA teams also document how a system should handle certain functionality internally as part of use case descriptions. By specifying such functionality we are imposing constraints on the development team to design the system in a specific way. Many would argue that “it is a BA’s job to think for all scenarios and provide a solution” but we forget that the real purpose of a use case is to describe what system does to fulfil the goals of the actor and by mentioning constraints inside a use case we are just making this behaviour difficult to understand. So, anything that must be handled in a certain way should only be described in the use cases and all other things should be left out for the developers to decide. Constraints can be captured in other specifications and traced back to the use cases so that they are not forgotten during the system design. Use case model must never be used to design the system. Use cases describe what the stakeholders want the system to do and not how the system implements the functionality.

9. Describing things outside scope of system

Use case model captures the interactions of actors and the system and describes what the system does to fulfil actor goals. Outside system boundary a stakeholder (identified as an actor) may interact with another stakeholder (who may be identified as another actor); to support the business process. If this interaction (business process) is not supported by the system, it should not be captured in the use case model. Use cases can be used to capture business processes as “business use cases” with actors outside the business boundary. Never mix systems use cases and business use cases.

10. Misusing the use case relationships

BA teams also spend lot of time structuring the use case model, with use case relationships such as include, extend and generalization, assuming that such structure is required in every use case model or required for the system’s architecture. BA teams typically useinclude relationship to break a use case into smaller use cases by performing functional decomposition of the system. The result is that none of the use cases by themselves provide any real value as it becomes very hard to see what a system does. Using use case relationships without understanding their real purpose just results into a confusing use case model.

About Author

Trividh Patel, CBAP® has well over a decade of experience in an IT services industry, in various functions such as Business Analysis, Business Technology Services, Presales, and Project Management, primarily in Banking, Financial Services, and Insurance domain.

Trividh has done his MBA from JBIMS, University of Mumbai, and Bachelor of Engineering from VJTI, University of Mumbai.

Trividh Patel, CBAP® provides specialized Business Analysis Trainings, such as

1. Fundamentals of Business Analysis
2. Mastering Use Case Modelling
3. CBAP® / CCBA® Certification Prep Course

Trividh Patel can be reached on -
LinkedIn: http://www.linkedin.com/in/trividhpatel

The Case for System Documentation aka "Developer Is No Longer King"

Adrian M. — Wed, 14 Jan 2015 23:01:00 GMT

If you are managing a team of business analysts or systems analyst you probably have two main goals in mind:
- to make sure your team understand the requirements (the real ones)
- to make sure that you develop a solution which makes sense in the context of your constraints.

The chances are that one of your biggest constraints is a current system. Few of us have the luxury of working on developing brand new systems starting with a clean slate.

Most of us need to be able satisfy the new requirements in the context of an existing system. But do you know what the current system does?

Do you know the “AS-IS” of your system?

At the core of the Agile manifesto is the call to value “working software over comprehensive documentation”.

I could not agree more!

After all – what good to anybody is the documentation if the software doesn’t work?

Unfortunately many proponents of Agile development tend to miss the fact that the agile manifesto does not say “no documentation”. Whether this is by mistake or by design, I don’t know.

But I do know that, as a business analyst or system analyst, decent documentation made my life much easier and saved my clients a ton of money.

Let’s assume for a second, that the software does work… and that whoever specified and implement the first version did such a great job that the software satisfies all the initial requirements.

But also assume that there’s not documentation!

Now you are hired as the next business systems analyst and are being tasked to help out with the development of version 2 of the software. You might be able to do a great job gathering the requirements but when it comes to specifying what needs to change about the system – you’re stuck! You don’t know what the system does… Yes – you can play with the current system and try to infer what it does but unfortunately the only documentation is “the code”.

Let’s be honest – the technical landscape is constantly changing and most business analysts (even the technical ones) do not have the time or the inclination to maintain enough development skills so that they would be able to navigate their way through a number of technical layers (databases & stored procedures, middle layers and services, web server code and client side-script, etc.) a variety of languages (SQL, C#, JavaScript, Java, etc.), as well as a mixture of architectural models (Client-server, SOA, n-tier, etc.)

You are now at the mercy of the developers – and hope that some of the ones which developed the first version are still around.

These types of environments are the ones where the developer is King. The analyst finds himself at the mercy of those who can read code and navigate the technical layers.

I am not advocating that, as a business analyst or system analyst, you do not increase your technical skills; I’m just saying that, unless you become a developer, you’ll need some level of system documentation to point you in the right direction.

As a rule of thumb here are a few project characteristics which would indicate that maintaining live system documenting might be advisable:

the project is large (with a large team)

the business domain is very complex

analysis is done on-shore but the development is done off-shore

the system is supposed to be in use for years to come (i.e. there will likely be lots of turnover in staff over the years)

regulatory requirements exist which require certain level of system documentation (at least in the area of security, legal compliance, etc.)

building services or components which will be re-used by other teams (the clients)

I will be the first to admit that maintaining decent (good enough) system documentation is not easy. In large teams and large projects you must have the commitment of the management (the folks with the money) to maintain system specifications.

I have worked on many a project where the initial set of documentation was quite good but as soon as the first “emergency” arose, exception was granted to code without specs which were supposed to be updated “later”. In such cases – “later” usually never comes.

Another must for your organization, if you’re going to maintain system specs, is guidelines and standards. Whatever level you decide to maintain your specs you must create and publish a set of standards for your documentation. This way everybody knows how to read it and how to keep it in synch with the code.

Do you maintain system documentation? Why or why not?

Adrian

The Need for a Recipe

Dahlia Biazid — Thu, 13 Sep 2012 07:50:00 GMT

Everyone knows what use cases are and their use in the software requirements process. We all know there are many ways to write them: logical, physical, to describe a manual procedure or an automated procedure. The purpose of State Diagrams is well-known to everyone in the field. They help us define the transitional lifecycle of an object moving and manipulated on within a system. Data dictionaries are important to describe the elements of each data entity or class. And so on.

It is like a toolbox to choose from. I could use the hammer to bang on a nail (its original use), or to open something (an innovative use). In my requirements projects (or rather sub-projects form software development for that matter), I can use any or all of these techniques to analyze the system at hand. The question is when? What is the best strategy to employ these tools and get results most efficiently and effectively?

Nevertheless, this question did not seem answerable; even worse, it was not even asked! Instead, I looked around for a sample deliverable or a template to follow, with the hope that they would give me a picture to visualize and help me put the pieces together; and hopefully relieve me from the need to have a strategy. The tactic worked to an extent, but not completely. I still did not know for sure which step to make at each time I went to see the client or sit to think about the requirements plan. Only until the project was complete was I able to see the picture. So naturally, I took longer than I should to complete requirements; and the results were not as satisfactory as I as well as everybody involved wished for.

What was missing was the method, the strategy, the cunning of a chef who knows which ingredient to add and the exact timing and portion. What was really missing - and seems to be still missing - is the "recipe".

Challenges with User Stories

Seilevel — Mon, 22 Nov 2010 17:44:00 GMT

A Promise to have a Conversation

I’ve been writing user stories for a couple of years now, and the best way I’ve heard how to describe them is that they are a promise to have a conversation. Enough information should be written down to give the reader an idea of what the gist of the story is (and to be able to roughly estimate a story point size to it), but the details are to be driven out during discussions between the product owner and the development team at the start of the sprint.

And that concept works well when the product owner and the development team are located in the same location. As a product owner, I could attend the daily scrum meetings; I was available to the developers/testers/technical writers to answer questions as they arose.

Recently, however, I’m working on a project where the development team is not located with the product owners. In fact, development may be done in several different locations around the world. This introduces several layers of complexity that a co-located team does not have. Not only is there distance differences between the various team members, but now we also introduce time zone, language and cultural differences as well. As a result, there is a greater documentation requirement than I have had to deal with before. While the promise to have a conversation still holds, the product owner is just not as available with a geographically diverse team.

Story Size – Large vs. Small

So one of the first hurdles to jump was what the appropriate size of the user story is. I’ve had some interesting conversations with various people about this topic, and opinions do vary. Some feel that user stories should tell an end-to-end story. But that can result in very large, very complex user stories. I do see value in these user stories, and I tend to call them epic stories. I prefer to take these epic stories and break them down into much smaller user stories.

One characteristic I try to keep in mind as I write a user story is that it should be small enough to be developed during one sprint. So it is critical to understand the size of the sprints within your organization, since I’ve heard of sprints lasting anywhere from 1 to 6 weeks. It also helps to get your development organization to provide you with some rough story point sizes, so you know if your stories are of an appropriate size or not. For any story that has a point size estimate that is larger than the velocity of the team during a sprint, that story needs to be broken down into smaller stories.

What to do with Business Rules?

Another challenge is business rules. With the project that I am working on, we have finished documenting the user stories, but they only tell part of the story. They tell what the user expects to see, but not how the system gets to those results. That is the role of the business rules.

Now, if the team were co-located in the same location, this is where the promise to have a conversation would come in. During that conversation, the business rules can be vetted and discussed. However, with the geographically dispersed team, much of this needs to be written down. The story and the business rules can still be discussed, however, with cultural and language differences, having something in writing for team members to read through before the discussion and to refer back to after the discussion is a necessity.

But what is the best way to document these business rules? Some can be documented with the acceptance criteria for the user story. But sometimes there is the additional needs to get even more detailed than that, to get to the actual “if, then” statements. Where is it best to document them? I don’t have an answer to that yet, and much may depend upon the tool chosen to store the user stories.

But I am certainly interested in your experiences…how have you solved this problem?

Let us know, or check out other posts. http://requirements.seilevel.com/blog/2010/10/challenges-with-user-stories.html

Abandon the use of Non Functional Requirements

Craig Brown — Thu, 24 Sep 2009 11:57:00 GMT

This model is provided by Don Firesmith of SEI. Note the lack of an NFR category.

Agile Business Analysis using UML

Gil — Thu, 26 Feb 2009 20:41:00 GMT

Following the lead of another forum, where the question was asked about the use of UML by Business Analysts, I would like to ask the same question when we come to Agile Analysis.

The answer is NOT simple and like all professional questions needs analysis. This means, I shall post a series of these blog pages, expanding one point at a time. I will NOT rush in and give you the answer now.

Business Analysis is a coat of many colours:
- It starts with the real business professional or consultant. They are masters of politics, hand waving and general waffle. Above all they speak 'Management speak' and that certainly does NOT include a solid diagramatic approach. They know that 'If a person has time to read a document, they are NOT a manager.' It is the members of this group who very often help make the decision to start a program of work on computer systems to meet some business. requirements. These are the people who read the documents aimed at managers. They are really Business Consultants.
- Then there are Real Business Analysts. These guys map out how the business works and how to change it. BPR is a term I most often associate with them. Producing a spec for a software system is something they can do if the need arises. BPMN is probably central to the diagramatic aspects of their work. Costing floor space, business growth etc is as important They do NOT need two products doing the same job, so UML is one of the many methods they need to know about without needing to be able to use it.
- Next comes the Computing Business Analyst. They analyse the business, including mapping Business Processes and identifying Business Requirements. They may also produce Business Requirements Documents, or respond to them with System Specifications, responses to tender. They work on the basis that if there is a relevant Business Process, it MUST be documented. This documentation is often very helpful to a person doing a full analysis of a Business requirement. They differ largely from the 'Real Business Analyst' in that they are brought onto a project in order to help create a new computer product; Real Business Analysts, are interested in how the business will respond to such a computer system, and the computing side is just a small part of their job.
- Finally, there is the Business Systems Analyst, for whom the Business Process Diagram is a necessary evel that they may sometimes have to resort to. These are the guys who really should be using UML. They should define the requirements for the computer system and ensure that someone designs and builds them. This is also the group that will have the greatest trouble talking to the potential end users, the project sponsors and the senior management.

These categories have been mapped out, just to show that the question is NOT a simple as it seems. You need to start with the definition of what or who a Business Analyst is. NO two BAs are ever the same. NO one BA ever does the same job twice. There are many shades of grey.

This changes the question from 'Should BAs use UML? into 'When should BAs use UML, if at all?

Finally, I will leave you with a thought for the next page. 'Do Business Analysts ever Analyse?'

Gil

Invest in User Stories

Craig Brown — Fri, 09 Jan 2009 12:01:00 GMT

User stories have a place in modern requirements management. They may not be going to replace use cases but you shoulod know how to write them well.

Invest In Good User Stories

View SlideShare presentation or Upload your own. (tags: agile scrum)

How to write Entity Relationship Diagrams

Craig Brown — Fri, 29 Aug 2008 04:29:00 GMT

E R Diagram

View SlideShare presentation or Upload your own. (tags: er diagram)

Cascade - that's all 13 Principles of mine: do you have any? win a free copy of my book.

David Wright — Wed, 18 Jun 2008 03:27:00 GMT

Thirteen is all you need, at least in this point in time. I may add to them as time goes by, but I would also like to hear from readers if they have any suggestions or thoughts or their very own principles for IT Projects success. Pleae offer them and maybe we can get them into the second edition of the book...which you all remember is available at http://www.lulu.com/content/2088656 .

In fact, if (and its a big if) I get a number of suggestions, I will judge which one to be the 'best' of the bunch; winner gets a free copy of the book.

And to get things going, a free copy of the book also goes to the first person to submit a suggestion, so be quick!

David W. Wright

Cascade Day 15 - Principle #13: Use Architecture to Manage and Integrate the Deliverables

David Wright — Sat, 14 Jun 2008 03:23:00 GMT

13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system.

This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assembled.

In parallel, a release schedule is a great approach to support delivery. Gather the usable deliverables into timed releases that go into production together. As per Principle #11, a Release each quarter is recommended. The business receives what they are paying for often enough to be of value, but not often enough such that assimilation of change is so frequent it causes chaos.

Cascade Day 14 - Principle #12: Parcel work into two-week periods

David Wright — Tue, 10 Jun 2008 03:16:00 GMT

12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire project scope has been addressed.

OK, a 64 word-long paragraph is pushing the boundary of a ‘Principle’, but this point is the basic building block of Cascade. Are two week periods too aggressive? I think not, based on experience. I find developers and a tester like to work in such quick bursts, as delivering more results faster makes anyone feel more productive and accomplished, and illustrates quickly what works and doesn’t work. However, small bits delivered quickly need to be integrated into an overall solution, which leads to Principle #13.

Cascade Day 13 - Principle #11: Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change

David Wright — Fri, 06 Jun 2008 02:59:00 GMT

#11. Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc.

I was lucky to learn this early in the 90's as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools were in use, but usually in limited numbers; MS Project, on the other hand, was readily available and budding Project Managers thought they could now plan the whole world for months or years in advance. What actually happened, however, was constant re-planning as the reality of business change and resource turnover always took their toll. As Napoleon said, "A plan is only good until the battle is joined." After that, one must adapt to the changes that will always come.

My own experience was on a large project that was broken into a dozen pieces, which were planned separately to a target 18 months away, at which point I was asked to integrate them into one plan while resolving resource conflicts. First thing we found was that MS Project of that time crashed when you reached around a thousand tasks.

So, it was around then that some IBM PM consultants were brought on to sort out this mess, and where I first heard the above principle. Yes, you need a plan to get started and to control a project over time. You can even sketch out a plan out over many months to see and communicate the big picture; but, do not commit to any target date over 3 months away, odds are you will miss it. This also means you should do the detailed planning only to the next target date, meaning the full WBS and resource assignment. (At the other end of the detail level, the IBMers also recommended that the shortest task in your WBS should be 2 weeks, no less, otherwise you are micro-managing.)

Once you have a detailed plan for three months, and a high-level plan for the rest of the project, you can add more detail to further target dates as the project progresses, as each interim target is reached or on a rolling month-by-month basis. The level of change in any 3 month period will be manageable, much more than over the whole project.

There is a more recent corollary to the three month principle; the age of the mega-project should be over by now. Any IS project that takes many months or years to deliver the system is destined to fail. Yes, large systems are still needed, but break them into pieces that can be delivered, ideally about every 3 months; longer than that and you start to slide back to the mega-project approach, while shorter than that will not produce enough of the system to be worth delivering to the business. All business works in 3 month quarter cycles anyway, IT should too.

Cascade Day 12 - Principle #10: Models are better than text

David Wright — Tue, 03 Jun 2008 03:00:00 GMT

#10. Models are better than text.

I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT). I must offer my respect to the many talented people who labored to produce these documents over the decades; these documents were at least a step up from no Requirements or Design artifacts at all.

Consider what a ‘model’ really is in general; it is a representation of a finished product in a scaled down version; engineers have been literally creating models of what they are going to build for centuries, for such reasons as testing out problems on a small scale, and for presenting a view of the end result to whomever may be paying for it.

At this point, though, let us abandon any other aspect of physical engineering as an analogy for Information Systems development. Software is different; while tools and bridges and buildings have been created to either extend or protect the physical capabilities of human beings, Information Systems are created to extend the our mental capabilities, to help our thinking.

Given that, software can still be engineered, but it is a different type of Engineering. Software or Information Engineering has existed as a known concept since the 1970’s, although anyone who thought to call themselves a software engineer usually incurred the wrath, or at least disdain, of the established Engineering Disciplines and Schools. I am not an engineer, would not claim to be one, but my understanding is that traditional engineering is addressing software within its disciplines. In the future, as software becomes even more critical to our well-being and safety, it may be that those who design and create software will have to be accredited engineers, just like the ones who design and build bridges. I think history shows that quite a few early bridges and other structures were prone to collapse before engineering principles started to prevent it. Software is only a half-century old, so even in the age of internet speed and high change, more time will be needed to bring software in line with other long time products.

In the meantime, it should be a goal all of us in the IT business to adopt useful aspects of engineering to improve the quality of software, and modeling is a key concept to adopt. It almost frightens me that many still promote programming as an art form, that code can be beautiful or exquisite in some way. Well, even the most obscure art needs an audience to appreciate it, and it can’t just be other artists. Software is a product to be used, not admired, so if anything, programmers of the past 50 years have been more like craftsmen, using individual skills and experience to produce useful ‘objects’ for society to use. The problem is that demand continues to out-strip programmer output (remember the backlog!), so improved, repeatable and transferable methods are needed to transform software development from a craft to a true industry.

Cascade Day 11 - Principle #9: Leave a record of what you have done, so the project will not miss you if you leave

David Wright — Thu, 29 May 2008 06:22:00 GMT

#9. Leave a record of what you have done, so the project will not miss you if you leave.

If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in “quick and dirty” projects where an operating result is produced, but no one else can understand the code that was produced. However, if the contribution involves producing quality artifacts as described in principle #8, there is always a point-in-time record of what has been accomplished so far, which can be used by new project resources to continue the project with minimal disruption.

Cascade Day 10 - Principle #8: It’s the Deliverable (that matters), not the Task

David Wright — Wed, 28 May 2008 06:31:00 GMT

#8 --> It’s the Deliverable (that matters), not the Task.

The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effective on an average project.

This means that the project work will be divided into many tasks, sub-tasks, etc. . . . Once assigned a task, it is the goal of a specialist to produce a deliverable/result/artifact that can be used by the next specialist to further the progress of the overall project. Unfortunately, this simple idea has been the starting point for literally hundreds of IS delivery methodologies, many which spend an inordinate amount of content explaining how to do a task, how to amass all the tasks in Phases, and often insisting that its way is mandatory for success.

What this can lead to is an over-emphasis on the how of IT project tasks, to the detriment of actually completing them with all due speed. Here we see the task that is 90% done for weeks, or the infamous ‘analysis paralysis’ where a project cannot seem to get past Requirements. Ends do not justify any means, but Ends must be delivered.

Cascade Day 9 - Principle #7: One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

David Wright — Tue, 27 May 2008 06:13:00 GMT

#7 One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

This is actually one of those “rules of thumb” that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.) This ratio combines with the specialization of principle #6 to form the strong basis for the Cascade effect covered in the last principle to come.

I will be using the most common ‘role titles’ of analyst, designer, developer, and tester for the remainder of these blog posts. Sometimes these roles have different names, and there are many other roles in IT overall, but these four are the most recognizable to anyone doing primarily project work. (And the Project Manager makes five! Can’t forget them…)

Cascade Day 8 - Principle #6 - Specialize – each member of a team assigned to a project should do what they do best for the length of that project.

David Wright — Thu, 22 May 2008 05:21:00 GMT

This principle supports #5. With limited resources, there is another strong tendency to have IT staff ‘wear multiple hats’ on a project, especially the Business Analyst who is asked to also be the Project Manager and/or Lead Tester. Rather than getting more than you are paying for, you get less as an IT Staffer skilled in one role spends more time performing the other roles than an appropriate specialist would, and is distracted from being productive in their primary role.

At any time, and perhaps more so currently, there will be debates about which is better, a generalist or a specialist. I will agree that a strong, experienced generalist who can cover a wide number of tasks is the best resource you can have. However, these people are rare, and the odds of having even one such person in your average IT department are low . So, make sure that your staff is doing what they do best as much as possible as often as possible.

(This is not to say that people may not learn new roles over time, either switching to different roles or aspiring to be that coveted generalist. However, this is the task of overall resource management, overhead which will take up some portion of a person’s productive time. This is why most project management methods usually assume only about 6 out of each 8 hours can be used on actual projects. This reduced availability speaks even more to the value of specialization at a point in time. It also speaks to the value of matrix management, where Project Managers manage the projects and Resource Managers handle the ‘care and feeding’ of the valuable IT staff assigned to projects.)

Don't forget, come and see me at http://stores.lulu.com/dwwright99 .

Cascade Day 7 - Principle #4 - Pick the right project(s) for the business

David Wright — Wed, 21 May 2008 05:46:00 GMT

Principle #4 - Pick the right project(s) for the business.

At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out?

No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pick up momentum and resources if a manager or two can see that they will benefit from the project. At some point, the project will bump into another one, usually because they both want the same IT staff or other resources. Strong managers can often come out of these resource conflicts with what they need for their project, while the other managers suffer from their project going on hold or being cancelled. Otherwise, the conflict is escalated until one common, higher manager has to step in and decide who gets what; and this is often the first time the higher manager has even heard about the projects.

I sat in on a senior management committee meeting where the progress to date of a grand project was presented and a request for a budget increase was made to complete the project. The CEO took all this in, and commented that this was very interesting, but given the sizable amounts of money and time expended so far, why the heck had he never heard of this project before? The next week my manager sent me to see the CIO, who charged me with coming up with a new process for defining, approving, and controlling IT projects, better known these days as ‘Project Governance’.

So, how do you pick the ‘right’ IT projects? First you have to make the choice explicit, avoiding the random start-ups described above; do encourage any and everyone to suggest possible projects. An active strategic and operational planning process will also tend to drive out new projects as senior and middle management look for IT assistance to reach their assigned goals. All these proposed project ideas then become input to a ‘gating’ process, supported by means of valuing the worth of a project like, but not limited to, cost-benefit analyses.

Next time - Principle #5: Once a project is started, finish it.

Cascade - Day 6 - Principle #3: Use Architecture to describe the business, before and after projects.

David Wright — Tue, 20 May 2008 05:28:00 GMT

Principle #3: Use Architecture to describe the business, before and after projects.

“Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Architecture”, “Enterprise Architecture”, and so on, so it must be important.

Why do we need Architecture?

Architecture is not an end in itself; Architecture exists because things need to be built.

Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.

Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.

Applied to IT, a component assembly approach is dominating the industry, from the OO approach of software development, to real-time use of defined services, as popularized by SOA. Specialized agent software is starting to assist in finding services and brokering between different services to perform transactions collaboratively.

For the average company using IT, architecture is needed because it needs focused IT functionality to deliver the highest current value, while trying hard to ensure that the function will work (“integrate”) with the next function that is needed.

It should be emphasized that this is Architecture for Information Systems.; there are methods and approaches being promoted for an overall “Business Architecture”, architecture for the whole business, not just IT. Originating from IT circles, they often look like an IT/IS architecture, which can be confusing. The Architecture in this book is definitely about Information Technology and Systems.

The good news is that you do not need to invent an IT Architecture method for your company. Many authors and vendors have methods available already. When starting out, I recommend investigating/adopting the architecture that started it all, the “Zachman Framework” as developed and enhanced by John Zachman. He devised a matrix framework that cross-references core information concepts against the levels of abstraction that are used by different audiences and participants in delivery of Information Systems. See www.zifa.com ...

The key benefit of the framework is that it illustrates how information concepts can be transformed through the levels to produce operating components of the needed Information Systems.

Last two points on Zachman:

- The cross points of the Concept columns and Abstraction rows are called “Cells”; each cell will group the methods or documents (artifacts) that describe the content of the cell. Zachman does not specify what artifacts to use, or what methodologies to use to create the artifacts. The things in each cell on the diagram are just suggestions.
Keep this in mind for Principle #10.

- The Framework looks two-dimensional, but it is actually multi-dimensional when artifacts in one cell are cross-referenced to artifacts in other cells, the most obvious example is What vs. How, i.e., what function creates specific occurrences of data.

Remember, be sure to visit my bookstore at http://stores.lulu.com/dwwright99

Cascade - Day 5 - Principle #2: Projects change the business, so know the overall business first

David Wright — Fri, 16 May 2008 05:15:00 GMT

Principle #2: Projects change the business, so know the overall business first

A never-ending discussion in IT circles is about how much IT staff need to know about the business that the information systems are supporting. It is high-lighted by every want-ad for an IT job that says previous experience in the employer’s industry is mandatory.

Is detailed industry knowledge and experience absolutely necessary for an IT job? No.

Can an IT staffer be effective with absolutely no knowledge of their employer’s industry? No.

As in many situations like this, the ‘Yes’ answer lies somewhere between the two extremes. Like a pendulum, the level of industry knowledge will vary across this spectrum, based on the specific organization, and by the particular IT role; e.g. Analysts need to know more than Programmers, and it justifiably argued that Testers need to know even more than Analysts.

So, some industry knowledge is required. I suggest from experience, however. that several week’s research on an industry is equivalent to several year’s work experience, as much of a person’s experience is rendered out-of-date by industry changes, or is too specific to the company they worked at. This is more true today than ever, as the ubiquitous Web makes information about almost anything available with a text string and few mouse clicks.

As a result, IT needs to know something about the business going into a project, and the willingness to learn more as a project progresses.

The addendum to this discussion, however, is how much does IT need to know about the specific way their employer conducts business when competing in their industry . Again from experience, I suggest that very little or no such knowledge is needed going into a project. The cliché that “a little knowledge is a dangerous thing” applies here. If IT people know too much about the current business, they may be unconsciously constrained when devising new IT solutions by ‘the way things have always been done here.’ In extreme cases, this can lead to an IT staffer having the delusional belief that they know more about the business than the systems users and their management.

Do not fall victim to this belief. IT is about underlying hardware and infrastructure, and the information systems that run on them. The systems’ users and their management --- supported by all the strategies, policies, procedures and rules that define and control the business --- will know the specifics of their business better than IT; their jobs depend on it.

This is not to imply that all business users & management are omniscient, or that the all business’s operate without duplications or errors, or that there are not things the business doesn’t know yet. In fact, effective use of IT can address many such issues in the operation of a business, but IT and IT people do this in support of the business; IT does not define the business.

So, know your business in order to support your business.

Cascade - Day 4 - Principle # 1: There is always more work to be done than people to do it.

David Wright — Thu, 15 May 2008 04:52:00 GMT

Let’s look briefly at what each principle means or implies; which will serve as introductions to subsequent posts that will cover the principles in more detail.

#1. There is always more work to be done than people to do it.

Bordering on glibness, this principle summarizes the reality of virtually all organizations and activities, not just Information Systems delivery. It implies that a group within an organization charged with delivery of end results will a have a back-log of work not yet done. The existence of such a back-log is in itself not a problem, it reflects the desire of an organization to solve new problems and proactively improve itself; the problem arises when it grows perceptively in size from management’s perspective, and the length of time a change item sits on the back-log increases such that it can be measured in numbers of months or years.

So, we must accept that there will be a backlog; fully eliminating it would mean that the delivery group (like IT) becomes redundant, or that the overall organization has stagnated. What must be done is to embrace the back-log; it is IT’s input material and should be managed as such.

Next time: Principle #2 - Projects change the business, so know the overall business first.

Cascade - Day 3 - Principles

David Wright — Wed, 14 May 2008 04:33:00 GMT

Like you, I have read my fair share of IT books and blogs, and each author has to decide how to best present what they are trying to communicate. One way is to describe the problems/opportunities of interest to the reader, then document the new approach or method that solves the problems, etc.; the reverse is to document the new approach/method first and then describe what problems it fixes, etc.

I would like to try a mixture of the two, in the context of a set of Principles that I think will put all the content of what I am going to write context. This is not an original idea, I must admit, as many manifestos and proclamations have been used to introduce new ways of things; the Agile Manifesto is well known, and I am a particular fan of the Business Rules Manifesto. These and others like them lay out the basic reasons for their existence and the value they provide.

Principles can be very effective; the best I have ever seen were created by Mao Tse-tung for the new Chinese Red Army after his first insurrection failed. His principals for protracted/attrition warfare were summed up in a sixteen character military guide that even an illiterate peasant could understand…

"Enemy advances, we retreat.
Enemy halts, we harass.
Enemy tires, we attack.
Enemy retreats, we pursue."

Effective words, against which I hope my own do not completetly whither in comparison.

So what are these new IT principles I propose?

1- There is always more work to be done than people to do it.

2- Projects change the business, so know the overall business first.

3- Use an overall Architecture to describe the business, before and after projects.

4- Pick the right project(s) for the business.

5- Once a project is started, finish it.

6- Specialize: each member of a team assigned to a project should do what they do best for the length of that project.

7- One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

8- It’s the Deliverable (that matters), not the Task.

9- Leave a record of what you have done, so the project will not miss you if you leave.

10- Models are better than text.

11- Partition large projects into 3 month phases, which is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc.

12- Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks ( 2 developers ), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development, carry on in cascading 2 week periods until all of the project scope has been addressed.

13- Given many medium to small software Deliverables, use architecture to manage and integrate the Deliverables into a complete system.

I consider these a work in progress so, like most inventors of new principles or practices, I have come up with an overall name to encompass them, for now and as they evolve. It is:

Next time, I will start to provide details on each Principle, starting (of course) with #1.

Cacscade - Day 2 - what can you do to be successful?

David Wright — Sat, 10 May 2008 03:53:00 GMT

The premise of these blog entries is that the situation described in the previous post can change, but it is usually slow-going; or worse, there can be an immediate channge when your department is outsourced; it happens. In the meantime, what can be done to be “successful” in your average IT department in your average company?

What has to be done is to deliver on all those change requests, and finish those current projects so you can start new ones (there will always be new ones). At risk of sounding like a psychedelic poster, this means accepting the things you can’t change and changing the things you can.

What can’t you change right now:

The installed base of legacy systems.

The backlog of change requests and bugs (even if you do manage to deal with a lot of these things, there will be new ones come along to take their place; that is job security).

Senior management’s’ conflicting priorities for IT.

What can you change (or at least start to change?)

The structuring and management of the IT projects.

Overall management of staff by skills/specialties.

Allocation of staff to the projects.

What will follow in this blog is my prescription for this change, supported by some war stories, lessons learned, and lots of ideas to try. Even an ‘average’ company has some unique aspects, so maybe not everything in this book will work for everyone, but I hope to give you enough that some will work. My own fervent belief is that visible success with IT projects may lead to softening/improvement of the things you can’t change right now.

And why should you believe me?

David Wright is a veteran of over 25 years in the IT trenches. He started as a programmer in the mainframe-dominated 80’s, followed by 20 years as a Business Analyst and Architect, supplemented with stints in project management and testing when limited resources required it.

Mr. Wright has spent time both in operational areas delivering enhanced and new business systems, and in research and development focusing on information system methodologies and tools. The companies he has served in these capacities have ranged from life insurance to express delivery to equipment leasing & financing. In those companies, he has supported both the operational business’ and supporting functions like Finance, Human Resources, and even IT administration systems.

Sound good enough? If so, lets get started.

Next time: Start with some Principles...

Cacscade - Day 1 - does this sound like where you work?

David Wright — Fri, 09 May 2008 03:42:00 GMT

Day 1:

I have recently made a major career change, moving from what I would now call a client company to a consulting company. It's an exciting change, but I don't expect to write about my new experiences at this time.

However, I had also been spending some time writing an extended piece about my experiences over the years working in several IT departments, especially to define a set of "better practices" for succeeding in a multi-project environment. (I read another blogger's point that claiming you have a "best" practice is the height of egotism, and it rang true to me, so I will stick with "better".)

This material appeared on a more general blog of mine, and out of it evolved "Cascade". It is not strictly about Business Analysis, but we do not work in a BA vacuum, we are always part of a team to deliver a product or service, and I can think of no better analogy than fast flowing water that swirls around rocks and other obstacles and emerages to fill a large body of water, a Cascade of information system deliverables that add to the overall portfolio of a company.

You can see the resulting book at http://www.lulu.com/content/2088656 , and read the first few pages. What I plan to do in this blog is feature the material from the forward/introduction (hopefully to pique your interest in reading the rest!).

First up: Does this sound like where you work?

The book was written for people who work at companies that have an IT department to support their non-IT business. In comparison, this blog is not written for people who work at IT companies; from Google on down to someone selling excel macros. The main reason is that I have not worked for an IT company and, although I have worked with many in customer-vendor relationships, I do not feel qualified to write about something I do not have experience with. However, even companies selling IT need some other IT to help run their business, so perhaps some of my experiences may overlap with theirs.

Given that, let us consider the vast majority of companies that are making automobiles or serving hamburgers or providing investment advice or any and everything else. In those companies you will find a department/division filled with IT ‘professionals’: Programmers, Project Managers, Analysts, Testers, Implementers, Operators, and loads of other specialists like Database Administrators and Network Engineers. (I use professional in quotes because long-standing professions like lawyers and engineers like to protect the use of the word.)

The name of this group has evolved generally to the ‘Information Technology Department’, or IT for short (no ‘D’ at the end); such past names as “Data Processing” or “Management Information Systems” seem to have faded away . As an acronym, “IT” is used interchangeably to name the department and describe the functional scope addressed by that department.

So, as we speed through the first decade of the 21st century and on into the next, what is the common situation that these IT departments face?

 It probably includes an installed set of information systems that are used by the business to control and report on its operations. There is always more than just one system, and possibly hundreds(thousands?), many doing the same work as many others. Some may be decades-old, a few may be recent and using fairly new technologies, with the implementations of the rest spread-out over the history of the department since that first ‘computing machine’ was purchased, with the wide range of development and operating technologies which that implies. (How along ago did you read that your mainframe computer was dead? Did it die? Not likely.) The still favourite term for describing this installed base is legacy systems.

 It probably includes a large back-log of requested changes to that installed base of systems, overlaid with a long list of problems/bugs in the systems that the business is currently ‘working around’ until they ever get fixed.

 It probably has an “IT Strategy” that describes in glowing terms how the above two cases will be remedied by moving to some new method or tool or one enterprise system… if the budget and resources can ever be freed up from fixing and changing the current systems.

 It is probably overseen by a senior management group (or steering committee or review board) that is charged with deciding what IT work is approved and carried out. This group may be formal or informal, and may only be one person in the end, the CEO or someone he/she has delegated it to; since IT costs money, the CFO is a common choice.
I n this structure, the head of the IT department (CIO is the hot title, of course) plays a committee secretary and/or facilitator role, who is supposed to assist the rest of management in making their IT choices. This is a difficult role, as the rest of management has a split-view of IT, that most of it is a waste of time and money, except for the work each one wants for their own department/division.

 There are probably a large number of current projects being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.

 It is staffed by a group of IT staff that has remained the same size in numbers, or has been reduced, while being charged with doing more work than ever: “Work Smart, Not Hard”., “Do More With Less”. Each person is probably assigned to many of those current projects, juggling the work and trying to determine what they should really be working on.
The overall morale and effectiveness of this staff depends greatly on the skills of their immediate management and more senior managers who provide some level of inspiration; if not, morale plunges and turnover increases.

Sound familiar? Then you have the same experiences as me, and I will be writing more entries for you.

Next time: what you can't change but, more importantly, what you can change...

Cascade - The Book

David Wright — Thu, 08 May 2008 02:55:00 GMT

This blog has been started because, like anyone who writes a bit for a living, I thought I had a book to write...so I did.

This blog also hi-lights the arrival of lulu.com, a website that will publish your book with the 'tarnish' of a vanity presss.

So, check both out at http://www.lulu.com/content/2088656 . The book is "Cascade - Better practices for effective delivery of information systems in a multi-project environment. "

Future posts will feature selections from the book, starting with the forward/introduction, so come back tomorrow!

David Wright

Carnival of Business Analysts #5 - Requirements Analysis

Craig Brown — Sun, 16 Dec 2007 18:22:00 GMT

The 5^th edition of the Carnival of Business Analysts has been published at Better Projects. This edition is focused on Requirements Analysis.

This is a series of blog posts that collect other blog posts on topics themed around the BABOK knowledge areas. Edition 5 is on Requirements Analysis.

Previous editions include Looking at the role of the BA, the BA and Quality, Requirements Planning and Requirements elicitation.

Read it here.